函數式程式設計 (Functional Programming) 在電腦出現之前就已經存在，長期以來在學術界流行，直到近幾年才出現比較多的實際應用，為甚麼會這樣呢? 我認為這是因為函數式程式設計從數學理論發展而來，它提倡遵循人類的邏輯推理方式而非機器的運行方式寫程式，也因此它天生就是抽象的，必須依賴程式語言以及底層函式庫來把抽象的概念轉換為機器指令，而既然存在轉換的過程，就必然會有效能上的損失。把時間回推到1985年，當時的經典遊戲《超級瑪利歐兄弟》的程式大小只有 40 KB ! 實在很難想像在這種硬體限制下如何有函數式程式設計生存的空間。

然而即使到了現在，硬體資源也不是可以無限制的揮霍，那 FP 到底有甚麼有甚麼魔力，讓很多人即使要承擔效能上的損失，仍然願意使用它呢? 我認為有這些原因

• 它的設計更貼合人類的邏輯推理方式，因此它能提供更好的開發與閱讀體驗
• 因為它基於數學理論設計，而數學理論是不會出錯的，出錯的只有可能是人
• 好的開發與閱讀體驗能降低開發者出錯的機會
• 即使開發者出錯也有很高機率在語意分析階段就檢查出來

有很多名言佳句可以佐證以上說法，例如 1991 年圖靈獎得主 Robin Milner 曾說

Well-typed programs cannot "go wrong"

注意這邊的型別指的是更廣義的數學型別理論中的型別(type)而非計算機記憶體分配用的型別(int, char)，在嚴謹的函數式程式設計中，所有元素包含函式本身都是型別，所以這句話也可以理解成數學理論不會出錯，會錯的只可能是使用這些理論的人。另一方面因為在嚴謹的函數式設計中，一切程式都是數學理論的實踐，因此他們總是可以被驗證是否存在邏輯錯誤，這導致了函數式程式設計也符合另外一個理念

Fail fast, fail cheap

越早發現錯誤，修正錯誤的成本越低，這在敏捷測試領域中大概是歷久不衰的理論了(關於測試滿推薦這篇文章，這裡就先不離題多介紹)，一般我們都認為單元測試已經是測試金字塔中成本最底層，然而型別驗證的成本又比單元測試的成本低的多。

總結來說雖然使用函數式程設計要付出不少代價，但正常來說要能解決以下問題

• 可讀性問題，複雜的程式碼可以藉由函數式程式設計變簡單，這是因為它把指令抽象化成人類的邏輯推演過程
• 可靠性問題，數學理論不會出錯、開發過程能又提早發現錯誤，在開發階段就能提高軟體可靠性

至於到底哪些使用 FP 的方式不正常，後續會有實際案例跟大家分享。